REMARKS 



Claims 32, 39-51, and 53-54 have been amended. Claims 1-33, 35-51, and 53-54 
remain pending in the application. Reconsideration is respectfully requested in light of 
the following remarks. 

Claim Objections 

The Examiner objected to claim 32 because the claim depended on itself. Claim 
32 has been amended to depend from claim 3 1 . Therefore, withdrawal of the objection to 
claim 32 is respectfully requested. 

Specification Objections 

The Examiner objected to the specification as failing to provide antecedent basis 
to claimed subject matter; specifically that the applicant's specification does not describe 
the "computer accessible medium" claimed in claims 38-51 and 53-54. Applicants note 
that "computer accessible medium" appears in claims 39-51 and 53-54, and not in claim 
38. Claims 39-51 and 53-54 have been amended to recite a computer accessible storage 
medium. Support for a computer accessible storage medium is found in the specification, 
page 166, line 30 - page 167, line 3, which describes a "storage media." Therefore, 
withdrawal of the objection to the specification is respectfully requested. 

Section 103(a) Rejections : 

The Examiner rejected claims 19-29, 35, 36, 39-49, 53 and 54 under 35 U.S.C. § 
103(a) as being unpatentable over Hermann et al. (U.S. Patent 6,633,757) (hereinafter 
"Hermann") in view of Humpleman et al. (U.S. Patent 7,043,532) (hereinafter 
"Humpleman"). Applicants respectfully traverse this rejection for at least the following 
reasons. 
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In regard to claim 19, contrary to the Examiner's assertion, Hermann in 
view of Humpleman fails to teach or suggest that the client device is further 
configured to directly request from the service device finformation] that describes an 
interface to access the service; and wherein the service device is further configured to 
provide said [information] directly to the client device over said direct point-to-point 
communication link. The Examiner cites Hermann, col. 13, lines 27-41, and Hermann, 
col. 13 line 66 - col. 14 line 22 in support of this assertion. Applicants respectfully 
traverse this assertion. Applicants can find nothing in those citations or elsewhere in 
Hermann that teach or suggest the notion of information that describes an interface to 
access the service , nor can Applicants find anything in those citations or elsewhere in 
Hermann that teach or suggest the notion that the client device is configured to directly 
request the information fthat describes an interface to access the service} from the 
service device, nor can Applicants find anything in those citations or elsewhere in 
Hermann that teach or suggest the notion that the service device is configured to provide 
information fthat describes an interface to access the service] directly to the client 
device over said direct point-to-point communication link. Hermann, col. 13, lines 27- 
41, states: 

Meta data are fed from the service discovery module 1 1 (SDM) via line 26 
to the MAC unit 12. "Meta Data" refers to information about the 
protocols and/or services... meta data mainly refers to services (e.g. 
service information provided in form of a list of services). 

In this citation, Hermann's "service information" is simply described as "a list of 

services", and is not described as anything like information that describes an interface 

to access the service. Hermann, col. 13 line 66 - col. 14 line 22 states in part: 

The device 10 maintains service information. This service information can 
be stored in device 10 in form of service entries in service lists 61 (herein 
referred to as record with information about services), as schematically 
illustrated in FIG. 6. Each service entry contains: service information, and 
preferably a service description (e.g., input/output type) A.sub.l, A.sub.2, 
B.sub.l, and an associated identifier (e.g. k or m). 
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Applicants can find nothing in the above citation from Hermann, or in FIG. 6 
which the citation refers to, that teaches or suggests that a "service entry" or a "service 
description" includes information that describes an interface to access the service. 

As to the Examiner's assertion that Hermann teaches the notion that the client 
device is configured to directly request the information [that describes an interface to 
access the service] from the service device and that the service device is configured to 
provide information [that describes an interface to access the service] directly to the 
client device over said direct point-to-point communication link, Hermann only teaches 
that "The SDM 11 uses the network connection 21, 22 to obtain lists of services from 
other devices and also to send/advertize the list of services provided on its own device 
24." (Col. 13, lines 62-65). However, this citation does not teach or suggest the 
limitations as recited in claim 19. 

In further regard to claim 19, contrary to the Examiner's assertion, 
Hermann in view of Humpleman fails to teach or suggest a client device configured 
to support a transport connection in addition to said direct point-to-point 
communication link, wherein said client device is further configured to make said 
document available to other devices over said transport connection and provide a 
bridge from said transport connection to said direct point-to-point communication link 
so that the other devices may access the service . The Examiner, regarding claim 19, 
relies on Hermann and cites column 14, lines 30-54. However, Hermann, whether 
considered singly or in combination with the other cited art, does not teach or suggest 
anything regarding a client making the document available to other devices over a 
transport connection and providing a bridge from the transport connection to the direct 
point-to-point communication link so that other devices may access the service. 

At the Examiner's cited passage, Hermann describes that a service-providing 
device may offer both services of its own (i.e., native services) and composite services 
that are provided by a combination of service-providing devices. However, no mention is 
made of a client device making a document, which describes an interface to access a 
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service, available to other devices. Nor does Hermann describe a client providing a 
bridge between a transport connection and a direct point-to-point communication link so 
that the other devices may access the service. Hermann's composite services involve 
multiple service devices acting in a coordinated manner to perform a composite service 
for a client (see, column 9, lines 16-31). The composite service is thus a service 
provided by the service-providing device. 

Multiple service devices coordinated by a service-providing device to provide a 
composite service to a client is very different from a client providing a bridge from a 
transport connection to a direct point-to-point communication link to a particular service 
so that the other devices may access the service. Hermann's composite services do not 
involve any sort of bridge from a transport connection to a direct point-to-point 
communication link. 

In the Office Action dated April 16, 2007, response to arguments section 6, 

the Examiner addresses point (a), "no mention [in Hermann] is made of a client device 
making a document, which describes an interface to access a service, available to other 
devices." The Examiner asserts "Hermann discloses that the services communicate via 
APIs. Humpleman is relied upon to show that the concept of a document is an obvious 
implementation of an API." In section 13, in remarks directed at claim 19, the Examiner 
asserts "Humpleman teaches a client device directly requesting to a service device a 
document that describes an interface to access a service provided by the service device 
(Humpleman, col. 12, lines 20-30); wherein the client device receives the document 
directly from the service device (col. 11, line 63 -col. 12, line 9), wherein said document 
comprises information describing how to access the service (col. 12, lines 20-30), and the 
client device uses the information for said document to access the service (col. 13 lines 
17-31)." 

Humpleman does teach that an API may be represented in XML ("The second 
block 54 provides a format for representation of an API in XML form for all devices 14, 
designated as an interface data type definition INTERFACE. DTD" (col. 12, lines 27-30). 
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For example, Humpleman teaches, in col. 12, lines 31-39, that "A software agent, 
designated as Tool A, utilizes a subset of the XCE definition for Service A, and uses the 
interface data type INTERFACE.DTD for Service A to create an XML form document, 
INTERFACE-A.XML. The document INTERFACE-A.XML describes the objects and 
methods supported by the Service A according to the document type definition 
INTERFACE.DTD for Service A." However, Applicants respectfully traverse the 
Examiner's assertion that Humpleman teaches wherein the client device receives the 
document directly from the service device, in col. 11, line 63-col. 12, line 9 or 
elsewhere. Humpleman does not teach or suggest that a client device (Service (or 
device) B 14 in FIG. 15) receives the INTERFACE-A.XML document directly from 
the service device (Service (or device) A 14 in FIG. 15). Humpleman instead teaches 
that "The INTERFACE-A.XML can be used by Service A for validity checks if it 
encounters an error in a received message. The INTERFACE-A.XML can also be used 
by a foreign Application such as Service B to determine the message format for Service 
A before communicating with Service A. Further, if a message from Service B to Service 
A causes an error, Service B can access the INTERFACE-A.XML document to diagnose 
the error." (Col. 12, lines 54-61). Note that nowhere in the description of FIG. 15 does 
Humpleman teach or suggest that Service B receives the INTERFACE-A.XML 
document directly from Service A. In FIG. 15, INTERFACE-A.XML is instead clearly 
illustrated as residing on Service (or device) A. Humpleman only mentions that 
INTERFACE-A.XML can "be used by... Service B to determine the message format for 
Service A" and that "Service B can access the INTERFACE-A.XML document to 
diagnose [an] error." Service B can clearly perform both of those functions without 
receiving the INTERFACE-A.XML document directly from Service A. N 

Moreover, FIG. 15 does not illustrate, nor does the accompanying description 
describe, Service A sending INTERFACE-A.XML to Service B, nor do FIG. 15 and the 
accompanying description illustrate or describe Service B receiving INTERFACE- 
A.XML from Service A. Instead, the only thing FIG. 15 illustrates is Service B sending 
"XML" to Service A. The accompanying description states "The server device B sends 
commands to the server device A." Thus, Humpleman seems to be indicating that the 
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commands are XML messages, which is consistent with the rest of the Humpleman 
specification and drawings. Furthermore, a thorough reading of the entire description of 
FIG. 15 (col. 12, line 10 - col. 13, line 31) makes it clear that Applicants' arguments 
above are consistent with Humpleman's description. Nowhere in col. 12, line 10 - col. 
13, line 31 or elsewhere does Humpleman teach or suggest anything like Service B 
receiving the INTERFACE-A.XML document directly from Service A. 

In col. 11, line 63-col. 12, line 9, Humpleman discloses "the interfaces (API) to 
such Applications 20 are made available over the network using API extensions . 
Preferably, the API extensions utilize a standard format, such as an XML-based interface, 
to provide overall interoperability." However, contrary to the Examiner's assertion, this 
citation does not teach anything like the notion that the client device receives the 
document directly from the service device. As is made clear in Humpleman's FIG. 15 
and the accompanying description (col. 12, line 10 - col. 13, line 31), Humpleman does 
not teach or suggest that INTERFACE-A.XML is "received directly" by Service B from 
Service A. Instead, INTERFACE-A.XML resides on Service (device) A, wherefrom it 
may be "accessed" or "used by" Service B. In other words, Service (device) A makes 
INTERFACE-A.XML "available over the network". Nowhere does Humpleman teach 
or suggest that Service B does or even may receive the INTERFACE-A.XML 
document directly from Service A. 

In the Office Action dated April 16, 2007, response to arguments section 7, 

the Examiner addresses point (b), "Hermann does not describe a client providing a bridge 
between a transport connection and a direct point-to-point communication link so that 
other devices may access the service", and point (d), "Hermann's service[s] do not 
involve any sort of bridge from a transport connection to a direct point-to-point 
communication link". The Examiner asserts "Hermann clearly discloses a device acting 
as a bridge between two devices (col. 9, lines 38-41) in a wireless network (col. 7, lines 
62-64)." Hermann's system is clearly directed at communications among devices on a 
wireless local network. Hermann makes this clear in the Abstract and elsewhere: 
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Scheme and apparatus (10) for distinguishing services offered by a 
service-providing device in adjacency of the apparatus (10) from services 
offered by a service-providing device not being in the apparatus' 
adjacency. All devices-including the apparatus-are part of a wireless 
local network. (Abstract) 

Hermann discloses in the citation and elsewhere that a first device in a wireless 
local network may host a "composite service" that may act to mediate between a 
provider (device) in a proximity set with the first device and a second device that is in 
different proximity set with the first device but that does not include the provider device. 
The first device would, so to speak, relay communications over the wireless local 
network between the second device and the provider device in accordance with a wireless 
local network protocol that is used on the wireless network. Note that according to 
Hermann all three devices are on the same wireless local network and would thus all 
communicate in accordance with the same wireless local network protocol. The second 
device and the provider device are on the same wireless local network, but not within 
visible or other proximity of each other so that they cannot directly communicate via the 
wireless local network protocol in use. Instead, the first device (also on the same 
wireless local network) "mediates" between the two other devices via Hermann's 
"composite services". Hermann's "mediation" as described is clearly and distinctly 
different from the notion of bridging from a transport connection to a direct point-to- 
point communication link, as is recited in claim 19. 

In the Office Action dated April 16, 2007, response to arguments section 7, 

the Examiner goes on to assert "Point-to-point links are part of the wireless network (col. 
7, lines 62-64)." This is true; however, in Hermann, a point-to-point link that is part of 
the wireless local network would be used to link and communicate between the 
provider device and the first device indicated above, and a point-to-point link that is 
part of the wireless local network would be used to link and communicate between 
the first device and the second device indicated above for which the first device is 
acting as a "mediator" to the provider device. All three devices are on the same 
wireless local network. Again, in Hermann, "all devices are part of a wireless local 
network" (Abstract). Again, Hermann's "mediation" between devices on the same 

09/656,588 (5181-72300/P5096) 19 Meyertons, Hood, Kivlin, Kowert & Goetzel., P.C. 



wireless network is clearly and distinctly different from the notion of bridging from a 
transport connection to a direct point-to-point communication link, as is recited in claim 
19 

In the Office Action dated April 16, 2007, response to arguments section 7, 

the Examiner goes on to assert "The service discovery modules are able to implement 

"transport" connections (col. 13, lines 27-31, the protocols are considered "transports")." 

This citation from Hermann simply states: 

Meta data are fed from the service discovery module 1 1 (SDM) via line 26 
to the MAC unit 12. "Meta Data" refers to information about the 
protocols and/or services. . . 

Applicants can find nothing in that citation that teaches or suggests anything at all 
like "the service discovery modules are able to implement "transport" connections" , as 
the Examiner asserts. The citation simply says that meta data are fed from the SDM via 
"line 26" to the MAC unit on a device (see FIG. 1A, to which this citation refers), and 
that "meta data" refers to information about the protocols and or services. This citation 
is describing the transferal of data from one module to another module within a device, 
and is not referring to communications over Hermann's wireless local network. This 
citation clearly does not teach or suggest what the Examiner asserts it teaches. 
Furthermore, this citation has nothing to do with the Examiner's cited col. 9, lines 
38-41 of Hermann, which refers to service mediation on a wireless local network. 
Furthermore, it is unclear as to what "the protocols" is referring to in this citation in any 
case. The Examiner's conclusion that "the protocols" somehow teaches or suggests a 
"transport connection" as recited in claim 19 is completely without basis, and without 
support from the Hermann reference. 

Furthermore, the Examiner asserts "the protocols are considered 'transports'". 
Applicants note that one of ordinary skill in the art would recognize the distinction 
between protocols and transports . The two concepts are clearly and distinctly 
differentiated in the area of computer network communications. 
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In the Office Action dated April 16, 2007, response to arguments section 7, 

the Examiner goes on to assert "The term "transport" connection is very broad and any 
application operating over a network can be considered to operate some form of 
"transport" connection. The applicant has provided no elaboration on how this claim 
should be interpreted." Again, one of ordinary skill in the art would recognize the term 
transport in relation to the area of network communications. In any case, claim 19 
distinguishes between the direct point-to-point communication link and the transport 
connection . The transport connection is clearly separate and distinct from the direct 
point-to-point communication link. In Hermann, a point-to-point link that is part of 
the wireless local network would be used to link and communicate between the 
provider device and the first device indicated above, and a point-to-point link that is 
part of the wireless local network would be used to link and communicate between 
the first device and the second device indicated above for which the first device is 
acting as a "mediator" to the provider device. All three devices are on the same 
wireless local network. The first device simply acts to mediate (relay messages between) 
the second device and the provider device. Hermann does not teach or suggest the 
notion of a direct point-to-point communication link and a separate and distinct 
transport connection for which bridging would be required. Hermann does not teach 
or suggest that the first device "supports a transport connection in addition to a direct 
point-to-point communication link". No bridging between a direct point-to-point 
communication link and a separate and distinct transport connection is needed in 
Hermann's system, particularly in Hermann's "service mediation", and Hermann does 
not teach or suggest such bridging between a direct point-to-point communication link 
and a transport connection. Mediating between two devices on a wireless local 
network, as described by Hermann, is clearly not the same as bridging between a 
transport connection and a separate and distinct direct point-to-point 
communication link as is recited in claim 19. 

In further regard to claim 19, the Examiner asserts in the Office Action 
dated April 16, 2007 that "it would have been obvious... to combine the teachings of 
Hermann regarding a method for accessing a service via a point to point link with 
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the teachings of Humpleman regarding the use of a specific document to provide an 
interface for accessing the service because Hermann states that a service description 
should be flexible and extensible (col. 7, lines 39-40) suggesting an XML solution 
such as that taught by Humpleman." Applicants note that combining Humpleman's 
disclosed use of XML with Hermann's discloses system would simply result in 
Hermann's disclosed system using XML for some purpose. However, such a 
combination would not result in what is recited in claim 19 of the instant 
application. 

Furthermore, Applicants note that claim 19 of the instant application does not 
recite the use of XML as a limitation. Thus, the Examiner's reasoning that "an XML 
solution such as that taught by Humpleman" when combined with Hermann would be an 
obvious combination that would produce something like what is recited in claim 19 of the 
instant application under the motivation that "Hermann states that a service description 
should be flexible and extensible" is without merit. 

Applicants remind the Examiner that to establish a prima facie obviousness of a 
claimed invention, all claim limitations must be taught or suggested by the prior art. In re 
Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 2143.03. As shown 
above, the cited references do not teach or suggest all of the claim limitations recited 
in claim 19 of the instant application. For example, the cited references, alone or in 
combination, do not teach or suggest wherein the client device receives a document that 
describes an interface to access a service directly from a service device. As another 
example, the cited references, alone or in combination, do not teach or suggest wherein 
the client device is further configured to support a transport connection in addition to 
said direct point-to-point communication link, and to make said document available to 
other devices over said transport connection and provide a bridge from said transport 
connection to said direct point-to-point communication link so that the other devices may 
access the service. Furthermore, obviousness cannot be established by combining or 
modifying the teachings of the prior art to produce the claimed invention, absent some 
teaching or suggestion or incentive to do so. In re Bond, 910 F. 2d 81, 834, 15 USPQ2d 
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1566, 1568 (Fed. Cir. 1990). As noted above, the Examiner's stated motivation for 
combining the references is without merit. Moreover, the Examiner's stated motivation 
is merely conclusory. Furthermore, combining the references would not produce 
anything like what is recited in claim 19 of the instant application. 

Thus, for at least the reasons above, the rejection of claim 19 is not supported by 
the cited art and removal thereof is respectfully requested. Similar remarks also apply to 
claim 39. 

The Examiner rejected claims 1-18, 30-33, 37, 38, 50 and 51 as being 
unpatentable over Hermann in view of Humpleman and further in view of Herman et al. 
(U.S. Patent 6,341,353) (hereinafter "Herman"). Applicants respectfully traverse this 
rejection for at least the following reasons. 

In regard to claim 1, Hermann in view of Humpleman and Herman fails to 
teach or suggest the client device directly requesting to the service device a document 
that describes an interface to access a service provided by the service device, and the 
client device receiving said document directly from the service device, wherein said 
document comprises information describing how to access the service. The Examiner 
cites Hermann, col. 13, lines 27-41, and Hermann, col. 13 line 66 - col. 14 line 22 in 
support of this assertion. Applicants respectfully traverse this assertion. Applicants can 
find nothing in those citations or elsewhere in Hermann that teach or suggest the notion 
of information that describes an interface to access the service , nor can Applicants find 
anything in those citations or elsewhere in Hermann that teach or suggest the notion that 
the client device is configured to directly request the information [that describes an 
interface to access the service] from the service device, nor can Applicants find anything 
in those citations or elsewhere in Hermann that teach or suggest the notion that the 
service device is configured to provide information fthat describes an interface to 
access the service] directly to the client device over said direct point-to-point 
communication link. Hermann, col. 13, lines 27-41, states: 
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Meta data are fed from the service discovery module 1 1 (SDM) via line 26 
to the MAC unit 12. "Meta Data" refers to information about the 
protocols and/or services... meta data mainly refers to services (e.g. 
service information provided in form of a list of services). 

In this citation, Hermann's "service information" is simply described as "a list of 

services", and is not described as anything like information that describes an interface 

to access the service. Hermann, col. 13 line 66 - col. 14 line 22 states in part: 

The device 10 maintains service information. This service information can 
be stored in device 10 in form of service entries in service lists 61 (herein 
referred to as record with information about services), as schematically 
illustrated in FIG. 6. Each service entry contains: service information, and 
preferably a service description (e.g., input/output type) A.sub.l, A.sub.2, 
B.sub.l, and an associated identifier (e.g. k or m). 

Applicants can find nothing in the above citation from Hermann, or in FIG. 6 
which the citation refers to, that teaches or suggests that a "service entry" or a "service 
description" includes information that describes an interface to access the service. 

As to the Examiner's assertion that Hermann teaches the notion that the client 
device is configured to directly request the information [that describes an interface to 
access the service] from the service device and that the service device is configured to 
provide information [that describes an interface to access the service] directly to the 
client device over said direct point-to-point communication link, Hermann only teaches 
that "The SDM 11 uses the network connection 21, 22 to obtain lists of services from 
other devices and also to send/advertize the list of services provided on its own device 
24." (Col. 13, lines 62-65). However, this citation does not teach or suggest the 
limitations as recited in claim 1 . 

In further regard to claim 1, in section 28, in remarks directed at claim 1, the 
Examiner asserts "Humpleman teaches a client device directly requesting to a 
service device a document that describes an interface to access a service provided by 
the service device (Humpleman, col. 12, lines 20-30); wherein the client device 
receives the document directly from the service device (col. 11, line 63-col. 12, line 
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9), wherein said document comprises information describing how to access the 
service (col. 12, lines 20-30), and the client device uses the information for said 
document to access the service (col. 13 lines 17-31)." Humpleman does teach that an 
API may be represented in XML ("The second block 54 provides a format for 
representation of an API in XML form for all devices 14, designated as an interface data 
type definition INTERFACE. DTD" (col. 12, lines 27-30). For example, Humpleman 
teaches, in col. 12, lines 31-39, that "A software agent, designated as Tool A, utilizes a 
subset of the XCE definition for Service A, and uses the interface data type 
INTERFACE. DTD for Service A to create an XML form document, INTERFACE- 
A.XML. The document INTERFACE-A.XML describes the objects and methods 
supported by the Service A according to the document type definition INTERFACE. DTD 
for Service A." However, Applicants respectfully traverse the Examiner's assertion 
that Humpleman teaches wherein the client device receives the document directly 
from the service device, in col. 11, line 63-col. 12, line 9 or elsewhere. Humpleman 
does not teach or suggest that a client device (Service (or device) B 14 in FIG. 15) 
receives the INTERFACE-A.XML document directly from the service device 
(Service (or device) A 14 in FIG. 15). Humpleman instead teaches that "The 
INTERFACE-A.XML can be used by Service A for validity checks if it encounters an 
error in a received message. The INTERFACE-A.XML can also be used by a foreign 
Application such as Service B to determine the message format for Service A before 
communicating with Service A. Further, if a message from Service B to Service A causes 
an error, Service B can access the INTERFACE-A.XML document to diagnose the 
error." (Col. 12, lines 54-61). Note that nowhere in the description of FIG. 15 does 
Humpleman teach or suggest that Service B receives the INTERFACE-A.XML 
document directly from Service A. In FIG. 15, INTERFACE-A.XML is instead clearly 
illustrated as residing on Service (or device) A. Humpleman only mentions that 
INTERFACE-A.XML can "be used by... Service B to determine the message format for 
Service A" and that "Service B can access the INTERFACE-A.XML document to 
diagnose [an] error." Service B can clearly perform both of those functions without 
receiving the INTERFACE-A.XML document directly from Service A. N 
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Moreover, FIG. 15 does not illustrate, nor does the accompanying description 
describe, Service A sending INTERFACE-A.XML to Service B, nor do FIG. 15 and the 
accompanying description illustrate or describe Service B receiving INTERFACE- 
A.XML from Service A. Instead, the only thing FIG. 15 illustrates is Service B sending 
"XML" to Service A. The accompanying description states "The server device B sends 
commands to the server device A." Thus, Humpleman seems to be indicating that the 
commands are XML messages, which is consistent with the rest of the Humpleman 
specification and drawings. Furthermore, a thorough reading of the entire description of 
FIG. 15 (col. 12, line 10 - col. 13, line 31) makes it clear that Applicants' arguments 
above are consistent with Humpleman's description. Nowhere in col. 12, line 10 - col. 
13, line 31 or elsewhere does Humpleman teach or suggest anything like Service B 
receiving the INTERFACE-A.XML document directly from Service A. 

In col. 11, line 63-col. 12, line 9, Humpleman discloses "the interfaces (API) to 
such Applications 20 are made available over the network using API extensions . 
Preferably, the API extensions utilize a standard format, such as an XML-based interface, 
to provide overall interoperability." However, contrary to the Examiner's assertion, this 
citation does not teach anything like the notion that the client device receives the 
document directly from the service device. As is made clear in Humpleman's FIG. 15 
and the accompanying description (col. 12, line 10 - col. 13, line 31), Humpleman does 
not teach or suggest that INTERFACE-A.XML is "received directly" by Service B from 
Service A. Instead, INTERFACE-A.XML resides on Service (device) A, wherefrom it 
may be "accessed" or "used by" Service B. In other words, Service (device) A makes 
INTERFACE-A.XML "available over the network". Nowhere does Humpleman teach 
or suggest that Service B does or even may receive the INTERFACE-A.XML 
document directly from Service A. 

In further regard to claim 1, the Examiner asserts in section 28 of the Office 
Action dated April 16, 2007 that "it would have been obvious... to combine the 
teachings of Hermann regarding a method for accessing a service via a point to 
point link with the teachings of Humpleman regarding the use of a specific 
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document to provide an interface for accessing the service because Hermann states 
that a service description should be flexible and extensible (col. 7, lines 39-40) 
suggesting an XML solution such as that taught by Humpleman." Applicants note 
that combining Humpleman's disclosed use of XML with Hermann's discloses system 
would simply result in Hermann's disclosed system using XML for some purpose. 
However, such a combination would not result in what is recited in claim 1 of the 
instant application. 

Furthermore, Applicants note that claim 1 of the instant application does not 
recite the use of XML as a limitation. Thus, the Examiner's reasoning that "an XML 
solution such as that taught by Humpleman" when combined with Hermann would be an 
obvious combination that would produce something like what is recited in claim 1 of the 
instant application under the motivation that "Hermann states that a service description 
should be flexible and extensible" is without merit. 

Applicants remind the Examiner that to establish a prima facie obviousness of a 
claimed invention, all claim limitations must be taught or suggested by the prior art. In re 
Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 2143.03. As shown 
above, the cited references do not teach or suggest all of the claim limitations recited 
in claim 19 of the instant application. For example, the cited references, alone or in 
combination, do not teach or suggest the client device receiving said document directly 
from the service device, wherein said document comprises information describing how to 
access the service. Furthermore, obviousness cannot be established by combining or 
modifying the teachings of the prior art to produce the claimed invention, absent some 
teaching or suggestion or incentive to do so. In re Bond, 910 F. 2d 81, 834, 15 USPQ2d 
1566, 1568 (Fed. Cir. 1990). As noted above, the Examiner's stated motivation for 
combining the teachings of Hermann with the teachings of Humpleman is without merit. 
Moreover, the Examiner's stated motivation for combining Hermann with Humpleman is 
merely conclusory. Furthermore, combining the Hermann and Humpleman references 
would not produce anything like what is recited in claim 1 of the instant application. 
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In further regard to claim 1, Hermann in view of Humpleman and Herman 
fails to teach or suggest the client device using the information from said document to 
access the service, wherein said using the information from said document to access 
the service comprises a client on the client device requesting a security credential from 
an authentication service specified in said document . The Examiner asserts that 
"Herman teaches a method of accessing a service comprising a client device receiving a 
document and using the document to access the service, wherein said using the 
information from said document (col. 42, line 59 - col. 43, line 31, the smart receipt) to 
access the service comprises a client on the client device requesting a security credential 
from an authentication service (col. 42, line 59 - col. 43, line 31, the transaction server) 
specified in said document." 

The Herman reference is directed at a "smart electronic receipt system that 
provides intelligent receipts , called Smart Receipts, that electronically document a 
transaction between two parties and maintains a persistent connection between the two 
parties following a successful online transaction." Herman is clearly not directed at 
anything like, and does not teach or suggest anything like, a client device forming a direct 
point-to-point communication link with a service device; the client device directly 
requesting to the service device a document that describes an interface to access a 
service provided by the service device; and the client device receiving said document 
directly from the service device, wherein said document comprises information 
describing how to access the service. Herman does not teach the client device directly 
requesting to the service device a document that describes an interface to access a 
service provided by the service device ; instead, Herman teaches that "a 
merchant... generate [s] a Smart Receipt at the conclusion of a successful transaction " 
(col. 43, lines 9-10). Herman does not teach the client device receiving said document 
directly from the service device ; Herman instead teaches that "A Smart Receipt is 
delivered over a secure connection from the merchant to a Trusted Agent Server , where it 
is stored and is made available to the customer " (col. 42, lines 59-61). Herman's 
intelligent receipts or "Smart Receipts" used in Herman's "smart electronic receipt 
system" are not described as anything like a document that describes an interface to 
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access a service provided by the service device, wherein said document comprises 
information describing how to access the service. Instead, Hermann states that Smart 
Receipts " electronically document a transaction between two parties . Smart Receipts 
maintain a persistent connection between two parties following a successful online 
transaction " (col. 42, lines 55-58). In other words, by the time the Smart Receipt is 
generated, the client (Herman's "customer") has already accessed the service 
(Herman's "merchant") to perform a transaction with the merchant. Thus, 
Herman's "smart electronic receipt system" in which a merchant (the "service") 
generates a "Smart Receipt" at the conclusion of a successful transaction with a customer 
and sends the "Smart receipt" to a Trusted Agent Server , and not directly to the client 
(Herman's "customer"), clearly does not teach or suggest anything at all like what is 
recited in claim 1 of the instant application. 

Furthermore, the Examiner asserts that col. 42, line 59 - col. 43, line 31 of 

Herman teaches "to access the service comprises a client on the client device 

requesting a security credential from an authentication service (the transaction 

server) specified in said document." First, nowhere does Herman teach of suggest that 

a "document" specifies an authentication service. Herman does not teach that the "Smart 

Receipt" "specifies" the transaction server. Herman only states, at col. 43, lines 

The XML representation of the Smart Receipt is transmitted over a secure 
connection to the Trusted Agent Server 1906 . The invention offers 
multiple options for transport, including Email and SSL. Authentication 
that uses SSL should use SSL certificates. The identity of the certificates 
are recorded on the Trusted Agent Database 1907. Email transport is also 
secure. 

The above citation teaches or suggests nothing like "to access the service 
comprises a client on the client device requesting a security credential from an 
authentication service (the transaction server) specified in said document". The citation 
is instead describing secure communications between Herman's "merchant" and 
Herman's "trusted agent server". Nowhere does Herman teach or suggest anything like 
the client (Herman's "customer") requesting a security credential from an authentication 
service. Furthermore, as noted above, by the time Herman's "Smart Receipt" is 
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generated, which this citation is related to, Herman's customer (the "client") has 
already accessed Herman's merchant (the "service"). Herman's "Smart Receipt" is 
generated by Herman's merchant at the conclusion of a successful transaction with a 
customer . 

Furthermore, neither Hermann nor Humpleman, whether considered singly or in 
combination with the other cited art, teaches or suggests anything about a client 
requesting a security credential from an authentication service specified in the document. 
Thus, Hermann, Humpleman and Herman, whether considered alone or in combination, 
fail to teach or suggest this limitation of claim 1 . 

In further regard to claim 1, the Examiner goes on to assert "It would have been 
obvious... [to] combin[e] the teachings of the Hermann-Humpleman combination 
regarding accessing a service with the teachings of Herman regarding the authentication 
of a user before allowing service access because though not mentioned in Hermann and 
Humpleman, it would be reasonable to believe that a user would want some level of 
security and the teachings of Herman are broad enough to apply the type of networks 
taught by Humpleman and Hermann (Herman, col. 3, lines 55-col 4, line 51)." First, 
Hermann is directed at "adjacency-bound service discovery" (Hermann, Title) in 
"wireless local area networks", and Humpleman is directed at "a method and system for 
performing a service on a home network " (Humpleman, Abstract). It is unclear as to 
how Herman's teachings of a "smart electronic receipt system" would apply in either of 
these "types of networks", and particularly how Herman's teachings of a "smart 
electronic receipt system" would apply to either Hermann's "adjacency-bound service 
discovery" or Humpleman' s "method and system for performing a service on a home 
network ". Furthermore, the Examiner wrongly asserts that Herman teaches "the 
authentication of a user before allowing service access". As noted above, Herman does 
not teach what the Examiner asserts Herman teaches. Herman's mention of 
"authentication" in the citation provided by the Examiner clearly occurs after the user 
(Herman's "customer") has accessed the service (Herman's "merchant"). Applicants can 
see no sense in combining Herman's "smart electronic receipt system" with the other two 
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references alone or in combination. Furthermore, even if Herman could be combined 
with the other references, the results would not be anything like what is recited in claim 1 
of the instant application. 

Applicants again remind the Examiner that to establish a prima facie obviousness 
of a claimed invention, all claim limitations must be taught or suggested by the prior art. 
As shown above, the cited references do not teach or suggest all of the claim 
limitations recited in claim 1 of the instant application. For example, the cited 
references, alone or in combination, do not teach or suggest wherein the client device 
receives a document that describes an interface to access a service directly from a 
service device. As another example, the cited references, alone or in combination, do not 
teach or suggest the client device using the information from said document to access the 
service, wherein said using the information from said document to access the service 
comprises a client on the client device requesting a security credential from an 
authentication service specified in said document. Furthermore, obviousness cannot be 
established by combining or modifying the teachings of the prior art to produce the 
claimed invention, absent some teaching or suggestion or incentive to do so. In re Bond, 
910 F. 2d 81, 834, 15 USPQ2d 1566, 1568 (Fed. Cir. 1990). The Examiner's stated 
motivation that "it would be reasonable to believe that a user would want some level of 
security and the teachings of Herman are broad enough to apply the type of networks 
taught by Humpleman and Hermann" is merely conclusory. The cited references include 
no motivation to combine Humpleman-Hermann with Herman. Neither Humpleman nor 
Hermann teach or suggest that any such security as described in Herman is desirable or 
necessary in their described systems, nor does Herman teach or suggest that such a 
combination is desirable or obvious. Furthermore, combining the references would not 
produce anything like what is recited in claim 1 of the instant application. 

Thus, for at least the reasons above, the rejection of claim 1 is not supported by 
the cited art. Similar remarks also apply to claims 37 and 38. 
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Applicants also assert that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the rejections have been shown to be 
unsupported for the independent claims, a further discussion of the dependent claims is 
not necessary at this time. 
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CONCLUSION 



Applicants respectfully submit that the application is in condition for allowance, 
and prompt notice to that effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
72300/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicants 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 
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Date: July 9, 2007 
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